 |
 |
Search: \.*
|
Topics in Dev web:
|
Changed: GMT
|
Changed by:
|
See http://pgmfi.org/phorum/read.php?f=5&i=5067&t=5067 for discussion.
I propose Pj RE (pronounced "pyre") as a short name for the PGMFI java ROM Editor.
I think dividing the App up into "layers" is going to be key to make it modular, portable and flexible. Each layer would probably best correspond with a java "package". (blundar) Pjre Layers
We are going to need to define a whole bunch of classes for data types. Pjre Classes
What, Why, and Who
What is it?
We are going to write a versatile, easy to use ECU ROM editor in the Java language.
Why?
So that all of us folks can pool our knowledge and write a very good Editor, something we can all be proud of. Also, it is being written in java so that it can be compiled and run on all different kinds of machines.
Who is writing it?
Anyone who wants to help. This is going to be an open source project. If you dont know java it is fairly easy to learn, and very easy to learn if you have prior programming experience in a high level language (C, C++, Visual Basic, whatever).
Guidelines for coding.
These are here so that we can make this go as smoothly as possible.
* Write code in a modular fashion. This means lots of classes, and classes that are going to be useful.
* Document the code you write. Please please please do this. Comments are your friend and they really help out the person trying to understand your code/logic.
* Use the java conventions. Class names have each word capitalized, constants are all caps, and var names have one LC word then a cap word (ie. thisVariable), etc. Also, try and make your variable names jive with their use. Try not to use variable names like a, b, c, etc (well, they are ok for loops, but use them wisely). Remember you have other people working with you.
Java Sources
Java package, tutorials and other stuff
Great Java editor
Ben Ogle?
the PGMFI java ROM Editor.
Classes grouped by layer:
Pjre UI Layer
The main ones, thus far (4.17.04)...
PjreDriver - Driver class, starts up the gui.
PjreParent - The parent frame that fits in the main frame. Contains menus and toolbars.
PjreChild - The child frames that fit in the parent frame. This class holds the graphical representation of the PRom object (tabs of tables, params, etc). Multiple instances of this can be created (multiple roms open at once).
PTabCtrl - Sets up the tabs that fit inside the child. These tabs hold the tables, the "info" tab, and the ROM parameters.
PTableCtrl - Sets up the tables so they arent a pain the ass to use for our application. Uses a couple of separate table models I (ben) wrote.
Pjre Engine Layer
Pjre IO layer
Pjre ROM representation layer
PRom (abstract class, all rom classes derived from PRom)
- OBD0NonVtec (another abstract, no need for instances of this)
- PM6
- PM6Ghettodyne
- PR4
- PM7
- etc
- OBD0Vtec
- OBD1NonVtec
- OBD1Vtec
- Other Roms?
I see layers as being key to this project working, both from a development and functional perspective.
(blundar)
What I mean by this is that there are various units of code (layers) that can communicate only with the layers immediately above and below. Interfaces between layers are well defined and documented. The top "layer" will be input - usually user input(potentially automated) This "layer" then interacts with the top layer of the software. Below the bottom layer of the software lies the actual permanent manifestation of the data itself, which initially will be a file on the user's computer (but could also be a PGMFI RTP connection or a ROMulator). (blundar)
Proposed Layers:
User Input (pseudolayer)
Input represents the top layer. As this is initially intended to be a ROM editor, user input will probably be the case. Any automated input could potentially talk directly to the Pjre Engine. (blundar)
Pyre Gui Layer
This layer is the GUI as would typically be defined. Representations of data classes from the Pjre Engine are displayed to the user, and opportunities are given to the user to view and change parameters. Any changes are made by updating data classes in the Pjre Engine. File IO is performed by making the appropriate call to the Pjre Engine layer, which is then responsible for making the appropriate IO call(s). Tabular, 2D and 3D views of arbitrary table sizes would be nice. A web/html oriented GUI might be a neat idea too. (blundar)
Pjre Engine Layer
The Pjre Engine is composed of the classes responsible for representing data and the methods for identifying, interpreting and manipulating it. It also is responsible for abstracting Load/Save/Update type IO calls based on the method used to acquire the current working data. (blundar)
Pjre IO Layer
The Pjre IO layer is responsible for opening ROM files from disk, retrieving ROM information via RTP connection, and/or any other method of ROM storage. Any and all low-level IO manipulation belongs here. (blundar)
Representation layer (pseudolayer)
In this psudolayer, representations of ROMs exist. These include but are not necessarily limited to files on disk, running images in a car accessed via RTP, running images in a car accessed via ROMulator and portions of a ROM as present in import/export files or hevaily modified ROMs
Tom H
Im a freelance web developer who is a newbie to PGMFI trying to donate any time I can to make it easier for other newbies to get on board and understand everything.
Email: Click Here
Web: http://webgeekwebdesign.com
Welcome to the PGMFI Dev Shed
Discuss building a Java Rom Editor
|
Topics in Dev web:
|
Changed: now 13:03 GMT
|
Changed by:
|
|
JavaRomEditor
|
14 Apr 2004 - 22:28 - r1.3
|
Home.Ben Ogle
|
|
See http://pgmfi.org/phorum/read.php?f 5 i 5067 t 5067 for discussion. I propose PjRE (pronounced "pyre") as a short name for the PGMFI java ROM Editor. I think dividing ...
|
|
|
PjreClasses
|
17 Apr 2004 - 01:02 - r1.2
|
Home.Ben Ogle
|
|
Classes grouped by layer: TOC Pjre UI Layer The main ones, thus far (4.17.04)... PjreDriver Driver class, starts up the gui. PjreParent The parent frame that fits ...
|
|
|
PjreLayers
|
14 Apr 2004 - 21:23 - r1.3
|
ROM
|
|
I see layers as being key to this project working, both from a development and functional perspective. (blundar) What I mean by this is that there are various units ...
|
|
|
WebGeek
|
18 Dec 2003 - 23:34 - NEW
|
Web Geek
|
|
Tom H Im a freelance web developer who is a newbie to PGMFI trying to donate any time I can to make it easier for other newbies to get on board and understand everything ...
|
|
|
WebNotify
|
25 Jan 2003 - 10:04 - r1.7
|
Peter Thoeny?
|
|
This is a subscription service to be automatically notified by e-mail when topics change in this Dev web. This is a convenient service, so you do not have to come ...
|
|
|
WebPreferences
|
14 Apr 2004 - 21:20 - r1.19
|
ROM
|
|
TWiki.Dev Web Preferences The following settings are web preferences of the TWiki.Dev web. These preferences overwrite the site-level preferences in TWIKIWEB . WIKIPREFSTOPIC ...
|
|
|
WebRss
|
30 Jan 2003 - 08:14 - NEW
|
Peter Thoeny?
|
|
TWiki's Dev web SCRIPTURL /view SCRIPTSUFFIX /Dev The web for users, groups and offices. TWiki is a Web-Based Collaboration Platform for the Corporate World. INCLUDE ...
|
|
|
WebStatistics
|
28 Oct 2007 - 02:18 - r1.249
|
TWiki Guest
|
|
Statistics for Dev Web Month: Topic views: Topic saves: File uploads: Most popular topic views: Top contributors for topic save and uploads: Oct 2007 140 0 0 44 WebPreferences ...
|
|
Number of topics: 14
See also the faster Web Topic List
This is a subscription service to be automatically notified by e-mail when topics change in this Dev web. This is a convenient service, so you do not have to come back and check all the time if something has changed. To subscribe, please add a bullet with your .WikiName in alphabetical order to this list:
Format: <space><space><space>, followed by:%BR%
* Home.yourWikiName (if you want that the e-mail address in your home page is used) %BR%
* Home.yourWikiName - yourEmailAddress (if you want to specify a different e-mail address) %BR%
* Home.anyTWikiGroup (if you want to notify all members of a particular TWiki Group)
Related topics: TWiki Users, .TWikiRegistration
TWiki.Dev Web Preferences
The following settings are web preferences of the TWiki.Dev web. These preferences overwrite the site-level preferences in .TWikiPreferences, and can be overwritten by user preferences (your personal topic, i.e. TWiki Guest in the TWiki.Home web)
Preferences:
- List of topics of the TWiki.Dev web:
- Top-right hand corner menu: list of destinations
- Web specific background color: (Pick a lighter one of the .StandardColors)
- List this web in the .SiteMap:
- If yes, Set SITEMAPLIST =
on, and add the "what" and "use to..." description for the site map. Make sure to list only links that include the name of the web, e.g. Dev.Topic links.
- Set SITEMAPLIST = on
- Set SITEMAPWHAT = Development ideas, brainstorming and documentation
- Set SITEMAPUSETO = ...collaborate on software development
- Exclude web from a
web="all" search: (Set to on for hidden webs)
- Default template for new topics and form(s) for this web:
- Web Topic Edit Template?: Default template for new topics in this web. (Site-level is used if topic does not exist)
- .Web Topic Edit Template?: Site-level default template
- .TWikiForms: How to enable form(s)
- Set WEBFORMS =
- Users or groups who are not / are allowed to view / change / rename topics in the Dev web: (See .TWikiAccessControl)
- Set DENYWEBVIEW =
- Set ALLOWWEBVIEW =
- Set DENYWEBCHANGE =
- Set ALLOWWEBCHANGE =
- Set DENYWEBRENAME =
- Set ALLOWWEBRENAME =
- Users or groups allowed to change or rename this WebPreferences topic: (I.e. TWiki Admin Group)
- Set ALLOWTOPICCHANGE = TWiki Admin Group?
- Set ALLOWTOPICRENAME = TWiki Admin Group?
- Web preferences that are not allowed to be overridden by user preferences:
- Set FINALPREFERENCES = WEBTOPICLIST, DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE, ALLOWWEBCHANGE, DENYWEBRENAME, ALLOWWEBRENAME
Notes:
- A preference is defined as:
6 spaces * Set NAME = value Example:
- Preferences are used as .TWikiVariables by enclosing the name in percent signs. Example:
- When you write variable
%WEBBGCOLOR% , it gets expanded to #D0D0D0 .
- The sequential order of the preference settings is significant. Define preferences that use other preferences first, i.e. set
WEBCOPYRIGHT before WIKIWEBMASTER since %WEBCOPYRIGHT% uses the %WIKIWEBMASTER% variable.
- You can introduce new preferences variables and use them in your topics and templates. There is no need to change the TWiki engine (Perl scripts).
Related Topics:
- .TWikiPreferences has site-level preferences.
- TWiki Users has a list of user topics. User topics can have optional user preferences.
- .TWikiVariables has a list of common
%VARIABLES%.
- .TWikiAccessControl explains how to restrict access by users or groups.
TWiki's Dev web
http://www.pgmfi.org/twiki/bin/view/Dev
The web for users, groups and offices. TWiki is a Web-Based Collaboration Platform for the Corporate World.
Statistics for Dev Web
Notes:
- Do not edit this topic, it is updated automatically. (You can also force an update)
- .TWikiDocumentation tells you how to enable the automatic updates of the statistics.
- Suggestion: You could archive this topic once a year and delete the previous year's statistics from the table.
See also the verbose Web Index.
Number of topics: 14
|
Copyright © 2002-present by the contributing authors. All material on this collaboration platform is the property of the contributing authors, and is covered by the Non-Commercial Share-Alike License unless explicitly stated otherwise. |
|